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Abstract — This paper will describe the progress of a 3 year 
research award from the NASA Earth Science Technology Office 
(ESTO) that began October 1, 2006, in response to a NASA 
Announcement of Research Opportunity on the topic of sensor 
webs. The key goal of this research is to prototype an 
interoperable sensor architecture that will enable interoperability 
between a heterogeneous set of space-based. Unmanned Aerial 
System (UAS)-based and ground based sensors. Among the key 
capabilities being pursued is the ability to automatically discover 
and task the sensors via the Internet and to automatically 
discover and assemble the necessary science processing 
algorithms into workflows in order to transform the sensor data 
into valuable science products. Our first set of sensor web 
demonstrations will prototype science products useful in 
managing wildfires and will use such assets as the Earth 
Observing 1 spacecraft, managed out of NASA/GSFC, a UAS- 
based instrument, managed out of Ames and some automated 
ground weather stations, managed by the Forest Service. Also, 
we are collaborating with some of the other ESTO awardees to 
expand this demonstration and create synergy between our 
research efforts. Finally, we are making use of Open Geospatial 
Consortium (OGC) Sensor Web Enablement (SWE) suite of 


standards and some Web 2.0 capabilities to leverage emerging 
technologies and standards. 

This research will demonstrate and validate a path for rapid, 
low cost sensor integration, which is not tied to a particular 
system, and thus be able to absorb new assets in an easily 
evolvable, coordinated manner. This in turn will help to facilitate 
the United States contribution to the Global Earth Observation 
System of Systems (GEOSS), as agreed by the U.S. and 60 other 
countries at the third Earth Observation Summit held in 
February of 2005. 

Keywords-Sensor Webs; interoperability; on-demand science, 
OGC, GEOSS, Web 2.0 

I. Introduction 

A sensor web is a set of disparate sensors tied together with 
a communications fabric that are controlled in such a way as to 
form a cohesive whole. Figure 1 depicts our vision for a user- 
centric sensor web architecture that enables the user to request 
a feature, such as a wild fire, and receive a set of feasible 
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Figure 1 An ontology translates feature requests by user into sensors and workflows that can produce the desired science product 








automatic workflows which can trigger selected sensors, 
algorithms and data delivery mechanisms to create the 
necessary science products. These science products are 
customized, assembled and delivered just-in-time. The key 
capability is an ontology, which can translate a feature into sets 
of sensors and workflows. Also, note that in figure 1, one of 
the branches of the tree is highlighted in red. This represents 
one possible workflow. So, there must also be a decision 
support tool to assist in picking which of the possible 
workflows is best. For our effort, we are experimenting with 
various methods to implement these capabilities. 

Note that this vision for a sensor web can enable the 
GEOSS vision. In the GEOSS agreement, many nations want 
to share their diverse set of sensor assets and be able to easily 
mix and match the various sensors that will be available into a 
temporary set of cohesive sensors to deliver a science product. 
The tools being developed and integrated into our sensor web 
will perform these functions. 

II. Operations Scenario 

Our original sensor web experiments began with the EO-1 
fire sensor web experiment that was conducted in August 2003 
[1], In this experiment, the MODIS instrument on the Terra 
spacecraft was used to survey major national wild fires as 
cataloged by the National Interagency Fire Center (N1FC) and 
then autonomously triggered a high resolution EO-1 image of 
the specified wild fire using a latitude/longitude of the hot spot 
pixels located and identified by the MODIS instrument. Later 
experiments included a volcano sensor web experiment ^2] in 
which various autonomous triggers could invoke EO-1 high- 
resolution images, which included MODIS, insitu sensors and 
even triggers from science processing occurring onboard EO-1, 
such as the detection of hot pixels. There were also additional 
experiments with floods, ice and dust. 

The scenario that we are developing for the summer 2007 is 
depicted in Figure 2. It is an expansion of our first wild fire 



Figure 2 Target Wild Fire experiment with OGC standards and Web 2.0 
capabilities 

sensor web experiment. For this case, we are adding Open 
Geospatial Consortium (OGC) Sensor Web Enablement (SWE) 


suite of standard services and some Web 2.0 capabilities. The 
key Web 2.0 capabilities that we plan to implement in our 
demonstrations are Really Simple Syndication (RSS), a method 
to publish frequently updated digital content and OpenID 2.0, 
an open, decentralized, free framework for user-centric digital 
identification. We may also experiment with geoRSS, which is 
Geographically Encoded Objects for RSS feeds in a news feed 
format. 

III. More on WEB 2.0 and OGC SWE Standards 
INTEGRATION 

The implementation of GEOSS will be influenced by the 
emergence of Web 2.0 and OGC SWE standards. These are 
not independent activities in that Web 2.0 capabilities will be 
used to implement some of the OGC SWE standards. In fact, 
that is one of the key goals of our activity. 

Web 2.0 is commonly understood as a transition of websites 
from isolated information silos to sources of content and 
functionality, thus becoming computing platforms serving web 
applications to end-users. It is also a social phenomenon 
embracing an approach to generating and distributing Web 
content itself, characterized by open communication, 
decentralization of authority, freedom to share and re-use, and 
"the market as a conversation”. It is also characterized by 
enhanced organization and categorization of content, 
emphasizing deep linking. Finally, Web 2.0 is characterized 
by a rise in the economic value of the Web, which in the 
science world, translates to more cost-effective and responsive 
science products. Earlier users of the phrase "Web 2.0" 
employed it as a synonym for "Semantic Web", and the two 
concepts do complement each other. 1 

The OGC SWE standards that we are using enable the 
following capabilities: 

a. Discovery 

b. Standard data access 

c. Standard tasking 

d. Standard alerts 

In particular we are using the following OGC SWE services: 

a. Sensor Planning Service (SPS) - is a standard web 
service interface for requesting sensor acquisitions and 
observations. This is an intermediary interface between 
a user and a sensor management system. 

b. Sensor Alert Service (SAS) - is a standard web service 
interface for publishing and subscribing to alerts from 
various sensors. 

c. Sensor Observation Service (SOS) - is a standard web 
service interface for requesting, subsets of data 
produced by selected sensors. 

We are also using additional OGC standard services as follows: 


1 Material from this paragraph was mainly taken from 
Wikipedia article on Web 2.0. 






a. Web Feature Service (WFS) - is a standard web 
service to allow requests for geographical features 
across the Internet using platform-independent calls. 

b. Web Processing Service (WPS) - is a standard web 
service that takes a defined set of geospatially 
referenced inputs, applies a specific calculation, 
defined by its owner, and produces a defined set of 
outputs. 

c. Web Coverage Service (WCS) - is a standard web 
service for exchanging geospatial data. WCS provides 
available data together with their detailed 
descriptions; allows complex queries against these 
data; and returns data with its original semantics 
(instead of pictures), which can be interpreted, 
extrapolated, etc. 

d. Web Map Services (WMS) - is a standard web 
service, which produces a digital image file and is 
often used to display data produced by a WCS on a 
map. 

e. Web Coordinate Transformation Service (WCTS) - is 
a web service used to transform geographically 
encoded data from one frame of reference to another. 

Our demonstrations and experiments will use the above- 
mentioned capabilities and services for as many sensor assets 
as we are able to integrate into our experiments. Our primary 
sensors are the Advance Land Imager (ALI), a multispectral 
imager, and the Hyperion, a hyperspectral imager, on EO-1, as 
depicted in Figure 2. We have the most control over the 
interfaces to this satellite and its sensor since the primary 
author is also the EO-1 mission manager. For other sensors, 
we are collaborating with other groups and therefore are often 
limited in how much of the above capabilities we can 
implement. 


the capabilities of the sensor. The capabilities may include 
location, resolution, spectral bands, swath and how to task the 
sensor. Furthermore, data processing algorithms are 
encapsulated as data processing nodes with SensorML or 
similar web accessible documents that describe algorithm 
functions. These descriptions may include inputs, outputs, 
methods employed by the algorithm and how to invoke the 
algorithm for user data. In both cases, the web accessible 
documents are created so that information about the sensors 
and algorithms can be discovered over the Internet and provide 
information on to how to access the sensors and algorithms. 
The user can then assemble sensor data and selected algorithms 
into a customized workflow or service chain in an automated 
fashion. This includes automatic electronic delivery of data 
products to the users’ computer desktop, thus enabling on- 
demand science products. 

Figure 4 represents the various ways the user may interact 
with the sensors and workflows. The most desirable interface 
would be the right most arrow in which the user intent is 
automatically translated into the appropriate sensor and 



IV. REFERENCE SENSOR WEB ARCHITECTURE 
Figure 3 depicts our reference sensor web architecture. 



Figure 3 Vision for a user-centric sensor web architecture 

Note that in this architecture, sensors are encapsulated as 
sensor data nodes with Sensor Markup Language (SensorML) 
web accessible documents that are XML-based descriptions of 


Figure 4 Levels of abstraction for user interactions going from left or right 
on the anows. The user would like to use the right most arrow since that is 
the easiest interface. 


workflow. Note that the various sensors, data nodes, data 
processing nodes and workflows may exist in distributed 
locations. The job of the workflow box and the reasoning 
function is to bring all the required resources together into a 
single functional flow. 

V. Detailed Operations Scenario 

Figure 5 depicts our first concrete workflow using only EO- 
1 and the various OGC compliant services that we are creating. 
Note that there are two parallel workflows. The first is to 
invoke one of the onboard classifiers to provide a quick but 
rough indication as to where the fire is located. The thermal 
summary that is rapidly downlinked, is a file containing shapes 
produced by the thermal classifier indicating hot spots, but the 
shapes are not geolocated. This gives the user a rough 
indication of where the fire is located. The other workflow 
involves the full image and uses classifiers on the ground. This 



image is geolocated; however the full processing chain may 
take a day or more to process and deliver to the user. 

Follow-on efforts this summer will involve building similar 
interfaces and workflows for the other assets mentioned earlier 
in this paper such as MODIS, ASTER and the Ikahana UAS. 
Also, will be integrating OpenID 2.0 at minimum into 
eol.geobliki.com and if possible into other components. We 
plan to use Really Simple Syndication (RSS) as the means to 
enable our SAS capability. Also through our collaborations we 
plan to explore different methods to performing discovery and 
building automatic workflows. 



Figure 5 The first wild fire workflow using just the EO-1 satellite 


VI. Partners 

We are collaborating with the U.S. Forest Service and the 
Ames Research Center (ARC) to implement this 
demonstration, which will include the National Interagency 
Fire Center (NIFC), Air Force Weather Agency (AFWA), 
Draper Labs, Terra, Aqua, EO-1, the Ikhana Unmanned Aerial 
System (UAS) and Remote Automated Weather Stations 
(RAWS). 

Additional details on the collaborators and other 
collaborators and their related work not in figure 2 are as 
follows: 

a. NASA Advance Information Systems Technology 
(AIST) award - Dynamically Linking Sensor 
Webs with Earth System Models: Principle 
Investigator (PI)I- Liping Di/George Mason Univ., 
Greenbelt, MD 

-Task involves methods to discover science 
products and invoke algorithm workflows 
automatically 

b. NASA AIST award - Increasing Technology 
Readiness Level (TRL) of SensorML - PI-Mike 
Botts/Univ. of Alabama, Huntsville, AL 


-Use SensorML for discovery and invoking 
algorithm workflows 

c. NASA AIST award - Sensor-Analysis-Model 
Interoperability - PI - Stefan Falke/Northrop- 
Grumman/Washington Univ. in St. Louis, MO 

- Standard model interfaces to drive sensor webs 

d. NASA AIST award - Sensor Web Dynamic 
Replanning: PI - Steve Kolitz/Draper Labs, 
Cambridge. MA 

- Decision support systems for sensor webs 

- Cloud screening for optimized tasking of 
satellite assets 

e. NASA AIST award - Using Intelligent Agents to 
Form a Sensor Web for Autonomous Operations: 
PI- K. Witt/WVHTF, Fairmont, WV 

- Help implement SensorML use to describe 
sensor capabilities for discovery 

f. NASA AIST award -Volcano Sensor Web: Pl- 
Ashley Davies/NASA- JPL, Pasadena, CA 

- Detect and image volcanoes autonomously with 
EO-1 

g. Wildfire Research and Applications Partnership 
(WRAP) - V. Ambrosia-NASA-ARC and E. 
Hinkley/US Forest Service 

— Unmanned Aerial System (UAS) to augment 
sensor web 

h. Remote Automated Weather Stations (RAWS) data 
access - J. Horel, Univ. of Utah, Salt lake City, UT 

- Data access to RAWS 

i. ASTER - PI - M. Abrams/JPL, Pasadena, CA 

— Possible ASTER data access for sensor web 
demonstration 


VII. Conclusion 

The sensor web experiments being conducted under the 
NASA AIST task described in this paper lay the groundwork 
for capabilities required to enable GEOSS. The real 
applications that are being built will add additional credibility. 
We have isolated the capabilities of discovery and automatic 
workflows as key capabilities to make future GEOSS 
architectures cost effective. 
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